wait WOW @thejonroberts thank you so much for jamming on this. You have made my month 😂

@thejonroberts thank you for the feedback on the following:

• Requiring ContactType (validation)
• Limiting to one answer per ContactTopic, as well as limiting number of topic answers to number of topics
• Showing ContactTopic description in tooltip. This will require swapping the tooltip out on topic select, and I thought there is a lot of javascript logic already.
• There may be some other minor things in the design document.
• I also think it would be good to make an issue for better accessibility. I tried to get the basics out of the way, but one thing that really bothers me is that the form is VERY difficult to tab-navigate through.

I can create some sep tix for these. As fo this PR @elasticspoon do we need an issue to tie this PR to?

@thejonroberts thank you for the feedback on the following:

• Requiring ContactType (validation)
• Limiting to one answer per ContactTopic, as well as limiting number of topic answers to number of topics
• Showing ContactTopic description in tooltip. This will require swapping the tooltip out on topic select, and I thought there is a lot of javascript logic already.
• There may be some other minor things in the design document.
• I also think it would be good to make an issue for better accessibility. I tried to get the basics out of the way, but one thing that really bothers me is that the form is VERY difficult to tab-navigate through.

I can create some sep tix for these. As fo this PR @elasticspoon do we need an issue to tie this PR to?

@thejonroberts just chatted with Mallory (designer) and confirmed that we should be Requiring ContactType - are you able to do a "hot fix" here or would you like a new ticket?

@bcastillo32 I can add the ContactType requirement here.

@bcastillo32 I can add the ContactType requirement here.

Ok great. Thank you so much @thejonroberts !

I have a long weekend so I'll have time to look over this in the next couple days

Hi @thejonroberts, this looks awesome! I'm really excited to see this single-page form coming together. I've just finished reviewing your work for design, so a lot of my feedback will be around aligning the style and UX with our Figma file. I've split this into parts that should be addressed immediately (if possible) and things that could be split into future tickets. Let me know what you think!

To address in this PR:

• Date auto-populating:
  In the past, some users have complained about submitting forms where data was automatically input for them, such as date. In the Figma file, I was hoping to address this by leaving the date field unpopulated until a user clicks on it. This initial click will still populate it with today's date, as well as open the calendar window.

• Days since the last contact:
  In the past, we've included an italicized "About 1 week ago" since the last contact note for each Contact Type. Can we add this back? Users found this helpful when filling out the form.
  .

• Contact Medium options:
  Can you render these options vertically instead of horizontally? This should increase clarity and accessibility.

• Including One Discussion Note:
  When the page is initialized, we should include one discussion topic and note. Users report wanting to be able to write their notes down quickly, so having a textbox already available should save them a click. Also, can you confirm that these Discussion Topics are being pulled from the organization's configuration? We'll be using these values to map the notes to their corresponding section in the generated court report.

• Limit to one entry per topic in Notes:
  If it's not too hard, can we limit the number of entries for each topic to one? I'm assuming this should also help our handling of these topics on the backend when generating reports so we don't have to stitch multiple entries per topic together.

• Reimbursement Visibility
  Can you confirm that the whole reimbursement card is only visible if the user's administrator has enabled reimbursement? Additionally, I cannot see the "Other Expense Amount" and "Other Expense Details" inputs in this section.

Additional feedback

Overall UI Feedback

1. Consistent horizontal padding - should match Figma
   1. Between "Relevant Case(s)" and "Contact Date"
   2. Between "Hours" and "Minutes"
   3. Between "Discussion Topics" and "Discussion Notes"
   4. Between "Total miles driven" and "Current address"
   5. Padding between the checkboxes and the circle checkboxes and the label should all be the same
2. Consistent vertical padding - should match Figma
   1. Between each "Discussion Notes" box (vertical padding)
   2. Padding between labels and their associated input box (ie, "Relevant Case(s)" and its input box)
   3. Align padding above "Recrd New Case Contact" with the Figma file
3. Align the copy to match the Figma file in the text boxes.
   1. For example, update alternative text in the "Relevant Case(s)" input box, from "Select or search" to "Select or search for case(s)"
4. Color for contact type Group Names should be #5D657B
5. Align sizes for textboxes, they should all be 20x20, see Figma. Similar note for the circles in the multiple choice questions (ie, "Contact Medium" options)
6. The options for "Contact Medium" should be vertical
7. All Labels should be Title Case, ie "Total Miles Driven"
8. Dummy text to be added where it's missing

Notes Section

1. The "Discussion Topic" should not be populated by default, with the "Select a discussion topic" alt text showing.
2. Are these topics hard-coded? They should be pulled from the admin control panel
3. The form should initialize with one Note visible. The topic should not be selected.
4. The alt text should be present in the Topic and Notes boxes if nothing is selected or inputted.
5. Color of the Discussion Topic and Discussion Notes should match the format of headers for other labels, ie "Relevant Case(s)," "Contact Dates"

Reimbursement Section

1. Are we including the "Other Expense Amount" and "Other Expense Details" input boxes? If not, let's make a ticket for them
2. Are we maintaining functionality where if an admin has not enabled reimbursement for this org, this whole box isn't viewable to the volunteer
3. The color of labels should match the format of other labels (similar to the above feedback in the Notes section)
4. Is it possible to make the height of the "total miles driven" and "current address" input boxes the same?
5. Update copy to "Mailing Address for Reimbursement Check"

Please let me know if you have any questions about my feedback. Great work so far!

@elasticspoon , @FireLemons Regarding the autosave questions and my previous comments:

• I could add a data-action="input->autosave#save" on every single input to fire off an autosave on every change

  • Where to show notifications? Top of every section? No design for these, my want to think on it.

• OR we could just autosave every X seconds

  • will save a lot of template actions, and make fewer server requests... unless someone walks away from their computer, and it just sends the same update over and over...

• Maybe a combo, autosave on any input, but stretch out the debounce time to like 30 seconds or a minute?

I think a decent and easy enough solution for now would be to add autosave actions for Additional Expense Description inputs. The expenses may also be difficult to remember/re-enter if you get logged out. I'll add that. I think everything else in the form is easy enough to re-do if you get logged out, and with notes/expenses at the bottom of the form, you will hit an autosave after you have filled them in (typically).

Does that sound like a good approach to y'all?

Yea. I'm good with that as an initial approach and we can see in the future if we need to change that.

Most of my stuff is just small comments but the drafts on the case details page (/casa_cases/:case_slug) don't appear, which is actually blocking.

@elasticspoon, that cannot be done currently in the app! I tried it out on main branch to confirm.

We don't set CaseContact.casa_case_id until the final submission of the contact. Selected case(s) are in draft_case_id column only. The CasaCase has_many :case_contacts relationship is not there yet, so Case show view is unaware of the drafts. You can only see draft contacts from the CaseContact index (/case_contacts).

@MalloryPriceDesign thanks so much for the detailed feedback! I have reworked the form quite a bit and it is much better now! Notes:

To address in this PR:

• Date auto-populating:

I have made the date input blank on load. Note that there is some weird behavior in Safari browsers - The date input's value is null, but it is displayed as today's date. So user may think it is set, but value is null and will error if form is submitted as is. This could be confusing, so I added basic browser validation to require an input before submit... I think that feedback could probably be improved, depends on the browser implementation.

I also could not get the CSS for input placeholder text color to work consistently for all inputs, I think due to our bootstrap setup. These issues would make good improvement tickets?

• Days since the last contact:
• Contact Medium options:
• Including One Discussion Note:
  When the page is initialized, we should include one discussion topic and note. Users report wanting to be able to write their notes down quickly, so having a textbox already available should save them a click. Also, can you confirm that these Discussion Topics are being pulled from the organization's configuration? We'll be using these values to map the notes to their corresponding section in the generated court report.

• There is one note shown on load now, unless editing an active contact that had no answers, or organization has no contact topics.
• These topics are from Organization's contact topics. If there are none available, a disclaimer is shown (as previously), and an 'Additional Notes' field is rendered for contact.notes column.

• Limit to one entry per topic in Notes:
  If it's not too hard, can we limit the number of entries for each topic to one? I'm assuming this should also help our handling of these topics on the backend when generating reports so we don't have to stitch multiple entries per topic together.

• I haven't done this yet but will try. I thought of a solution that is likely workable - disabling options that are currently selected... adding and removing completely from list of options is more complicated. Going to attempt it now.
• I think case contact report will be affected. (uses index_by(&:contact_topic_id): last topic answer will be shown, not others)
• EDIT: this is now implemented - topics that have been selected are disabled in other selects, 'Add..' button disabled after answers match the number of topics

• Reimbursement Visibility
  Can you confirm that the whole reimbursement card is only visible if the user's administrator has enabled reimbursement? Additionally, I cannot see the "Other Expense Amount" and "Other Expense Details" inputs in this section.

Yes, the entire Reimbursement section card is not rendered unless organization driving reimbursement is enabled.

1. Are we including the "Other Expense Amount" and "Other Expense Details" input boxes? If not, let's make a ticket for them
2. Are we maintaining functionality where if an admin has not enabled reimbursement for this org, this whole box isn't viewable to the volunteer

Expenses are behind another feature flag (also in Organization Edit available to admin), so they are not shown unless Driving Reimbursement & Expense reimbursement are both enabled. Note that this means creator must request driving reimbursement to request Other Expenses... So you can have no reimbursement, driving reimbursement only, or driving & expense reimbursement. But not only Expense reimbursement.

Additional feedback

Overall UI Feedback

Reworked classes and CSS to be much more consistent with design. Pretty close I think, the Figma files were extremely helpful, thank you.

Notes Section

1. The "Discussion Topic" should not be populated by default, with the "Select a discussion topic" alt text showing.

This is a little more complex than I want to deal with right now. Because of a database constraint on contact_topic_id (not null), we need a topic id when a new contact topic answer (Discussion Note) is added to the form. I think this could be implemented if the database constraint is removed, which would then allow us to require the Topic ID conditionally. Alternatively, could do some (overly complicated imo) javascript manipulations? Regardless, I think it is better left for future work.

EDIT: I am going to try just removing the database constraint... This would actually help with the one entry per topic mentioned above. This is implemented now.

Reimbursement Section
4. Is it possible to make the height of the "total miles driven" and "current address" input boxes the same?

The only way to do this (easily) means that it can only be a one line entry, as opposed to a more traditional address format, is that okay? Will wait to make the change until that is confirmed.

@MalloryPriceDesign - ready for re-review, see above, edited some notes I made earlier. (may need to be deployed to the environment you were looking at, I'm not sure how that was setup)

@elasticspoon - ready for re-review, with the caveat that I have not addressed the CasaCase show page draft issue, as I don't think that was a feature prior to this work, unless I'm missing something.

Reimbursement Section
4. Is it possible to make the height of the "total miles driven" and "current address" input boxes the same?

The only way to do this (easily) means that it can only be a one line entry, as opposed to a more traditional address format, is that okay? Will wait to make the change until that is confirmed.

Let's keep this as-is, I think the users will probably expect the traditional address format instead of a one-line format.

@MalloryPriceDesign - ready for re-review, see above, edited some notes I made earlier. (may need to be deployed to the environment you were looking at, I'm not sure how that was setup)

That's great! I used Codespaces to review previously. However, after running git pull and building the app again in my previous Codespace, I got an error. I restarted with a fresh Codespace and am getting the same error:

This page isn’t working
supreme-disco-rj9q4grx54jfppxg-3000.app.github.dev is currently unable to handle this request.
HTTP ERROR 502

I'll take a look again later.

Most of my stuff is just small comments but the drafts on the case details page (/casa_cases/:case_slug) don't appear, which is actually blocking.

@elasticspoon, that cannot be done currently in the app! I tried it out on main branch to confirm.

We don't set CaseContact.casa_case_id until the final submission of the contact. Selected case(s) are in draft_case_id column only. The CasaCase has_many :case_contacts relationship is not there yet, so Case show view is unaware of the drafts. You can only see draft contacts from the CaseContact index (/case_contacts).

You are right. My flabbers are ghasted. I totally thought that was something that could be done.

Looks amazing! I rebuilt my Codespace container and it's working now!

This looks good! The only change I would suggest is to enable the calendar dropdown to display on the initial click into the date box. Currently, the user has to go all the way to the right calendar icon to click to open the calendar. Is that something that could be easily changed? If not, I don't think this should block merging and can always be addressed in another ticket.

Thank you, Mallory...

This looks good! The only change I would suggest is to enable the calendar dropdown to display on the initial click into the date box. Currently, the user has to go all the way to the right calendar icon to click to open the calendar. Is that something that could be easily changed? If not, I don't think this should block merging and can always be addressed in another ticket.

This is browser dependent -- Safari opens date picker on click for example. I think any changes to browser input behavior should be separate to make sure time can be spent ensuring cross-browser behaviors and accessibility considerations are maintained, a lot of gotchas can pop up!

wow wow wow!!